Hackers Underworld 2: Forbidden Knowledge/Hackers Underworld 2: Forbidden Knowledge.iso/VIRUS/COMP.VIR

Internet Message Format | 1990-05-20 | 8KB

From cucard!rockyd!cmcl2!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw Fri Apr 20 16:55:42 1990
Path: dasys1!cucard!rockyd!cmcl2!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: [e-mail] (Peter da Silva)
Newsgroups: comp.virus
Subject: Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...}
Message-ID: <[e-mail]>
Date: 20 Apr 90 20:55:42 GMT
Sender: Virus Discussion List <[e-mail]>
Lines: 152
Approved: [e-mail]

> I have to believe that the same yahoos who think viruses are fun
> things on single-user OS machines like PCs and Macs would love to
> infect Unix and VMS systems, if they could.

They can.

> I really do believe that these systems are more difficult to
> circumvent, and this has, to some extent, accounted for great disparity
> in the number of successful attacks on these systems as compared to the
> single-user boxes.

I believe you're right, *but* source code has little to do with it.

It's been at least 6 months since I posted this little fable.

            The Usenet virus: a case history.
                A cautionary tale.

        The Usenet virus was detected when a user discovered that
    a  program  he  had  received  from  the  net  seemed to have two
    versions of malloc included  with  the  source.  One  version  of
    malloc  might  be odd, but people have never tired of reinventing
    the wheel. Two versions were suspicious, particularly since  they
    lead to a name conflict when the program was linked.

        The first, lmalloc.c,  seemed  to  be  identical  to  the
    malloc  listed  in  Kernighan and Ritchie. The second, bmalloc.c,
    was rather strange, so we concentrated our efforts on it...  this
    time was later found to have been wasted.

        After a little work during spare moments over the  course
    of  a  week  we  decided  it was actually a clumsy version of the
    buddy system (a  fast  but  space-inefficient  method  of  memory
    allocation).  It  might  make  a good example of how not to write
    readable code in some textbook, but it  wasn't  anything  to  get
    worried about.

        Back to the  first.  It  made  use  of  a  routine  named
    speedhack()  that  was  called  before  sbrk() the first time the
    malloc() was called. There was a file speedhack.c, but it  didn't
    contain  any  code at all, just a comment saying that it would be
    implemented in a future  version.  After  some  further  digging,
    speedhack  was found at the end of main.c. The name was disguised
    by some clever #defines, so  it  never  showed  up  in  tags  and
    couldn't be found just by grepping the source.

        This program turned out to be a slow virus. When  it  was
    run,  it  looked  for  a  file 'lmalloc.c'. If it found it, or it
    didn't find Makefile,  it  returned.  From  then  on  malloc  ran
    normally.

        If it didn't find it, it reconstructed it using a  series
    of  other  routines  with innocuous names tagged on to the end of
    other files. This was  apparently  an  attempt  to  avoid  overly
    increasing the size of any one of the files in the directory.

        Then it went into Makefile or  makefile  (it  looked  for
    both) and  added lmalloc.o onto the end of the first list of '.o'
    files it found. It then reconstructed each of the extra routines,
    and speedhack itself, using techniques familiar to any reader  of
    the  obfuscated 'C' contest. These were tagged onto the  ends  of
    the  '.c'  files that corresponded to the '.o' files in this same
    list.  The program was now primed to reconstruct the virus.

        On inspection,  we  discovered  that  about  40%  of  the
    sources   on  our system were infected by the speedhack virus, We
    also found it in one set of shell  archives  that  we'd  received
    but never unpacked or used, which we took as evidence that it had
    spread to a number of other systems.

        We have no idea how our system was infected.   Given  the
    frequency  with  which  we  make  modifications and updates, it's
    likely that the original speedhacked code is  no  longer  on  the
    system.   We  urge you to inspect your programs for this virus in
    an attempt to track it to its source.  It   almost   slipped   by
    us...  if  the  author  had  actually  put  a  dummy speedhack in
    speedhack.c we would have  merely  taken  lmalloc.o  out  of  the
    Makefile  and  defused *this* copy of the virus without being any
    the wiser.

        There are other failings in this  program  that  we  have
    thought  of. We have decided not to describe them to avoid giving
    the author of this program ideas we might regret.  Some ways that
    programs like this can be defeated include 'crc' checks of source
    files  and,  of  course,  careful examination of sources received
    from insecure sites.

- -----

Now I have to make a confession. This whole document is a hoax intended
to dramatize the problems involved with viruses and Usenet. I suspect that
most of you were clued to this by the Keywords line. While playing with the
idea and writing this article several things occurred to me:

First of all, this virus is a much more complex program than any of the
viruses that have been spotted on personal computers. I think it has to be,
based on the design goals that a REAL UNIX virus must satisfy. I have not
attempted to actually implement it because of this.

    It must be small, to avoid detection. It must not cause files to
grow without bound.

    It must infect foreign files, otherwise it's not a virus... just a
Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses
are a dime-a-dozen.

    It must infect source files, since this is the primary software
distribution channel for UNIX. A virus stuck on one machine is a boring
one.

    It must not break the infected program (other than what it might
care to do deliberately).

    It must not be obvious from a simple examination of the source (like,
changing main to Main and having a virus-main call Main).

I believe that given these goals (which are, of course, subject to
debate) a simpler program would be successful in infesting more than a
small fraction of the machines that (say) comp.sources.misc reaches.

There are systems immune to this particular attack, of course. Ones not
running UNIX, so sbrk() doesn't work. Or ones with radically different
versions of malloc(). Ones with no 'c' compiler. They are in the minority,
though.

On the other hand a virus of this type could infest a large proportion
of the net before it was found. The virus I described does not cause any
direct damage, except for using up a relatively small amount of disk
space. A more vicious virus is possible.

Other variations of this virus are obviously possible. For example, it
could be tagged onto any standard 'C' library routine... I chose malloc
merely because source was available and because it's something that people
complain about, so they wouldn't be likely to find an extra copy suspicious.
Another good routine would be perror(), for the same reason. This would have
the additional benefit of making the spread of the infection dependent on
an additional random factor, making it harder to detect the virus.

Do I think something like this is likely? No. Especially not now that
I've written this little piece of science fiction. I'm sure that
eventually someone will try something unlike this, I suspect that their
virus would get caught much sooner than 'speedhack', because I think
that more people look at the source than conventional wisdom would lead
you to believe. But, again, this is just my personal opinion. Debate is
welcomed... that's why I did this in the first place: to inject some
sense into the debate currently raging in comp.sys.amiga.

- --
 _--_|\  `-_-' Peter da Silva. [phone].      <[e-mail]>
/      \  'U`  Have you hugged your wolf today?  <[e-mail]>
\_.--._/
      v        Disclaimer: People have opini